<p>This rule raises an issue when <code>instanceof</code> is used to check the type of built-in JavaScript objects like <code>String</code>,
<code>Number</code>, <code>Array</code>, <code>Object</code>, etc.</p>
<h2>Why is this an issue?</h2>
<p>Using <code>instanceof</code> to check built-in object types has significant limitations that can cause your code to behave unexpectedly.</p>
<p>The main problem is that <code>instanceof</code> checks whether an object was created by a specific constructor function. This works fine for
custom classes, but built-in objects can exist in different "realms" (execution contexts). For example, an array created in an iframe has a different
<code>Array</code> constructor than an array created in the main window, even though they’re both arrays.</p>
<p>When you use <code>instanceof Array</code> on an array from a different realm, it returns <code>false</code> even though the object is clearly an
array. This can break your type checking logic and cause bugs that are hard to debug.</p>
<p>Additionally, <code>instanceof</code> doesn’t work correctly with primitive values. For example, <code>"hello" instanceof String</code> returns
<code>false</code> because string literals are primitives, not String objects.</p>
<p>These issues make <code>instanceof</code> unreliable for type checking built-in types, especially in complex applications that use iframes, web
workers, or other execution contexts.</p>
<h3>What is the potential impact?</h3>
<p>Using <code>instanceof</code> with built-in objects can lead to incorrect type detection, causing your application to behave unexpectedly. This is
particularly problematic in applications that work with multiple execution contexts (iframes, web workers) where the same type of object might fail
<code>instanceof</code> checks. The result can be runtime errors, incorrect data processing, or security vulnerabilities if type validation fails.</p>
<h3>How to fix?</h3>
<p>For primitive types (string, number, boolean, bigint, symbol), use the <code>typeof</code> operator instead of <code>instanceof</code>. This is
more reliable and works correctly with both primitive values and their object wrappers.</p>
<h4>Non-compliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
if (value instanceof String) { // Noncompliant
  console.log('It is a string');
}

if (value instanceof Number) { // Noncompliant
  return value.toFixed(2);
}
</pre>
<h4>Compliant code example</h4>
<pre data-diff-id="1" data-diff-type="compliant">
if (typeof value === 'string') {
  console.log('It is a string');
}

if (typeof value === 'number') {
  return value.toFixed(2);
}
</pre>
<h3>Documentation</h3>
<ul>
  <li> <a href="https://github.com/sindresorhus/eslint-plugin-unicorn#readme">eslint-plugin-unicorn</a> - Rule <a
  href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/HEAD/docs/rules/no-instanceof-builtins.md">no-instanceof-builtins</a> </li>
  <li> MDN - instanceof operator - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof">Comprehensive
  documentation about the instanceof operator and its limitations</a> </li>
  <li> MDN - typeof operator - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof">Documentation about the
  typeof operator for type checking</a> </li>
  <li> MDN - Array.isArray() - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray">Documentation
  about the recommended way to check if a value is an array</a> </li>
  <li> @sindresorhus/is package - <a href="https://www.npmjs.com/package/@sindresorhus/is">A comprehensive type checking library for JavaScript</a>
  </li>
</ul>
